昨天我們把產品需求整理清楚了：PRD、痛點分析、Function Map、MVP 切分，一份輕量版的食譜總算慢慢成形。

食譜有了，接下來就該挑烤箱和工具了。

只是走進工程世界的工具間，我才發現——架上的東西比甜點店還多。

一個完整的專案，最基本有哪四塊

在真正開始做專案以前，我很常跟朋友分享：

「我最近學了JS、Node.js、PostgreSQL、Express……」

但真的要我解釋它們各自負責什麼、彼此之間又是什麼關係時，我其實講得沒有想像中清楚。

我那時候比較像是分開學會了：

「這個東西怎麼用。」

卻還沒有把它們拼回一個完整的網站裡。

所以我可以寫一些程式碼，卻不一定說得清楚自己現在用的是程式語言、執行環境、框架，還是資料庫。

也是開始做完整專案之後，我才慢慢把這些原本分散的知識接起來。

在講技術選型以前，可以先把一個完整專案最基本的角色拆成四塊：

• 前端：負責畫面呈現與使用者互動
• 後端：負責業務邏輯、處理請求，並和資料庫溝通
• 資料庫：負責資料的儲存與讀寫，開發時可以使用本機資料庫，上線後則連接正式環境的資料庫
• 雲端部署：把前端、後端程式放到網路上的環境執行，讓使用者可以直接透過網址使用，而不是只能在自己的電腦上跑

知道它們各自做什麼之後，下一步就是把它們串起來看：

使用者在畫面上的一次操作，到底是怎麼一路送到後端、資料庫，再把結果送回畫面的？

把這張流程真的跑過幾次之後，我才開始覺得：

「喔，原來我以前分開學的那些東西，是這樣接在一起的。」

選一個技術之前，該判斷哪些事？

搞懂每一塊的角色之後，下一個問題就來了：

每一層可以選的東西這麼多，到底要怎麼選？

真正走進工具間之後，才發現每一層都有一整排可以選。

Vue、React、PostgreSQL、MongoDB、Render、Vercel……

對新手來說，很像站在一整面工具牆前面，什麼都看得懂名字，卻不知道到底該拿哪一個。

先看一些常見選項：

第一次看到這種表，很容易直接陷入：

「Vue 還是 React？」
「PostgreSQL 還是 MongoDB？」
「到底哪個比較好？」

但後來我才發現，真正要問的其實不是：

「哪個最好？」

而是：

「哪個最適合現在這個專案？」

我後來把技術選型整理成幾個很實際的問題：

• 產品需要什麼？
  有哪些功能？資料量多大？要不要即時更新？SEO 重不重要？有沒有第三方登入？產品不同，技術重點也會跟著變。

• 團隊會什麼？
  就算 A 技術理論上更適合，如果整個團隊只熟 B，硬換過去也不一定划算。團隊熟悉度本身就是一個現實條件。

• 有多少時間？
  時程越短，越需要考慮熟悉度、生態成熟度、部署難度。技術再漂亮，最後做不完也沒有意義。

• 資料長什麼樣子？
  像使用者、好友、活動、報名、投票這類資料之間關係很多時，關聯式資料庫通常會比較自然。真正該問的不是「MongoDB 和 PostgreSQL 誰比較強」，而是「我的資料比較適合哪一種模型」。

• 上線之後要面對什麼？
  成本、安全性、維護難度、效能、部署方式，都會影響最後的選擇。

最後還有一題，我現在覺得特別重要：

為什麼是它，不是另一個？

真正的技術選型不是只說：

「我們用了 Vue。」

而是至少能解釋：

「我們選 Vue，是因為團隊熟悉、時程又短；React 也做得到，但現在切換過去的成本，換不到足夠的好處。」

對我來說，能回答這一句，才比較像是真的做過選擇。

BuJo 實際是怎麼選的？

但真的輪到 BuJo 要挑工具時，我們沒有站在工具牆前慢慢研究。

回到現實條件：

我們是學程式大約四個月的新手團隊，開發時程大概一個半月，而課程本身教的就是 JavaScript、Node.js、Express、PostgreSQL。

所以前面那幾個問題裡，光是：

「團隊會什麼？」
「有多少時間？」

其實就已經幫我們排掉很多選項。

這些技術理論上都可以換，但在時間和能力有限的情況下，我們沒有另外花大量時間去學一整套新的工具，而是先用已經熟悉的技術把專案完成。

但「用已經會的」不代表所有地方都直接照抄同一套答案。

同一個需求，放在不同位置，選擇也會不一樣

測試框架就是一個很直接的例子。

前端選 Vitest，是因為它跟 Vite 整合得很好，不需要另外維護一套複雜設定；但到了後端，沒有 Vite 這個前提，這個優勢也就不存在了。

所以後端我們改用生態更成熟、範例和資源更多的 Jest。

同一個需求，換了使用情境，答案就可能跟著改變。

有些缺點可以接受，但要知道自己換來了什麼

部署平台也是一樣。

BuJo 後端用了 Render。

當時我們知道免費方案會休眠，第一次喚醒時速度會比較慢；但對一個沒有付費預算、時程又很短的團隊來說，免費方案加上部署方便，仍然值得我們接受這個代價。

所以我們保留了這個選擇，同時補上載入畫面，避免等待時讓使用者以為網站壞掉。

這次選擇也讓我第一次很具體地感受到：

技術有缺點，不代表不能選；重點是你知不知道這個代價，而且有沒有準備好怎麼處理。

那麼今天的主題——技術選型，在 Vibe Coding 和專業開發上的差異在哪呢？

如果是 Vibe Coding，很容易直接問 AI：

「我要做這個產品，應該用什麼技術？」

AI 很快就能幫你配好一套看起來合理的工具。

但問題是：

合理，不一定等於最適合。

如果只告訴 AI「我要做一個揪團排程平台」，它只能用一般情境幫你判斷。

但如果把 Day 2 整理好的需求，再加上團隊能力、時程、預算和限制一起交給它，它才能更接近真正適合這個專案的答案。

所以差異更像是：

• Vibe Coding：先讓 AI 幫你挑工具，再直接開工
• 專業開發：先把需求和限制整理清楚，再讓 AI 幫你篩選，最後自己決定要接受哪個 trade-off

就像做甜點，不是看到別人都用某台烤箱，就代表它一定適合今天這份食譜。

先知道自己要做什麼，才知道該挑什麼工具。

工具不是越高級越好，適合這份食譜才重要

回頭看這一關，我現在最確定的是：技術選型不是逛工具店挑最厲害的那一個，而是替眼前這份食譜，選一套最適合的工具。

真的進到專案裡，答案很少只取決於工具本身。

我們會什麼、剩多少時間、有多少預算、產品需要做到什麼程度，這些現實條件都會一起影響最後的決定。

有些選擇很快就能拍板。

有些則沒有完美答案，只能問：

「這個優點，值不值得我接受它的代價？」

像 Render 的休眠問題，我們不是不知道，而是知道之後，還是覺得當下值得選。

這種「知道自己在換什麼」的感覺，是我做完 BuJo 之後才真的開始理解的。

食材備好、工具也選了，那「這罐是糖還是鹽」呢？

明天，來聊資料模型設計。